REMARKS 

The present Office Action (made FINAL) continues to reject all claims 1-29, setting 
forth identical bases for rejection (paragraphs 6-19) as those set forth in the previous Office 
Action. Applicant continues to disagree, and hereby incorporates by reference the remarks 
from the response filed on August 27, 2004. In addition, Applicant sets forth the following 
additional comments, which respond to the responsive arguments set forth in paragraphs 3-5 
of the present Office Action. 

Among other features, claim 1 of the present application defines "selecting a 
repository on one of the server computers based on one or more routing tokens in the file 
transfer request, wherein the routing tokens include one or more attributes describing the file, 
the client computer or an originator of the file transfer request." The Office Action 
(paragraph 4) alleges that these features are taught by Nakai at col. 6 lines 55-65, col. 7, lines 
22-26, and col. 7, lines 37-56. Applicant respectfully disagrees. 

Significant distinctions between claim 1 and Nakai are manifest in the purpose and 
operation of the two different systems. For example, a purpose of embodiments of the 
present invention is for relaying content upstream or downstream through a gateway, in such 
a manner that the client does not have to know the identity (e.g., machine name, IP address, or 
other identifier) of the server at the far end of the relay. Instead, the client describes 
something about itself to the gateway, and the gateway infers (or determines) an appropriate 
end-server from that, without the client's knowledge. This was emphasized in the previous 

response, in which Applicant stated: 

More specifically, claim 1 defines a system for file transfer 
between geographically and organizationally distant end points (a 
"customer reppsitory" aka "client computer" at one end, and a set of 
"supplier repositories" aka "server computers" at the other end). This 
system utilizes as many common off-the-shelf components as possible, as 
is noted in many places in the specification of the present application (see 
e.g., paragraphs 0067-0071). 
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One unique component in the embodiments of the present 
application is what has been called the "transport gateway, " and in 
particular its routing capability. The transport gateway resides between the 
client and the plurality of repository servers; when the client performs file 
transfer with a repository server of some kind, it connects to the gateway, 
not the repository server directly; rather, the gateway picks the right 
repository server (using the routing capability) and connects to it on the 
client's behalf. 

By this routing capability, the client does not have to know what 
repository server to connect, nor tell the transport gateway what repository 
server to connect. Instead, the client tells the gateway (by means of 
routing tokens included by the client in its request) some attribute(s) about 
the client context that the gateway will understand, and the gateway maps 
from those attribute(s) into the precise repository server that is appropriate 
for that context. For example, the client might provide routing tokens in its 
request describing the user itself: the type of organization (private 
business, government agency, etc), the type of business relationship the 
user has with the supplier of the gateway and repository server (support 
customer, vendor, etc), the scale of organization (small/home office, mid- 
size, enterprise, etc), the location of the user (e.g, country), etc.. As 
another example, the client might provide routing tokens in its request 
describing the file being transferred: the nature of its content (hardware 
diagnostic report, software inventory report, executable software, purchase 
order, etc), the name of the application that produced it or for which it is 
intended, etc. In each case, these routing tokens "describe" the context of 
the particular client request. The gateway then chooses the right repository 
server that the supplier has designated as appropriate for handling file 
transfers for that context. This component (which component is more fully 
explained in the specification), among others, clearly defines claim 1 over 
the cited because it abstracts the repository servers to the client. 
Therefore, when repository servers change - which realistically happens all 
the time in a large supplier organization - the gateway's routing capability 
shelters the customer from that change. The customer merely continues to 
describe his request context in the same way, and the supplier merely 
changes the routing rules to adapt to the change in the repository server 
pool accordingly. This solves one of the major potential breakage points in 
any large-scale long-term data-exchange architecture (e.g., shifts in 

topology). 

Nakai does not teach or even contemplate such a robust functionality. Instead, Nakai 
specifically teaches that the server machine name (and port) will be specified by the client 
(e.g., col 6 lines 62-63). The system of Nakai further describes the use of that same machine 
name (and port) to connect to the specified machine as the end-server (e.g. col 7 line 25, 
where "...the CM server...", which is the target of the proxy's request, is clearly the server 
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whose server machine name was specifically given directly by the client as "CM" in col 6 line 
62). Nakai wholly fails to disclose or suggest a feature, whereby the client request does not 
itself identify the end-server machine by name and port. Rather, the system disclosed in Nakai 
has the client request specify the end-server machine by name and port, but using a different 
protocol than that which is native to that end-server, so that protocol conversion is necessary 
(that being the essence of the invention — i.e., see 7 lines 20-21). 

In contrast, claim 1 of the present application defines a system having a "transport 
gateway . . . comprising computer instructions for . . . selecting a repository on one of the 
server computers based on one or more routing tokens in the file transfer request, wherein 
the routing tokens include one or more attributes describing the file, the client computer or 
an originator of the file transfer request" Further, the present application has defined 
routing tokens (see paragraph 0087 of published application 2002/0104022 Al) as "tokens 
known to the Customer Repository and presented for purposes of Supplier Repository routing 
to the Transport Gateway. ..." Simply stated, the machine name, IP address, or other identifier 
of Nakai does not properly anticipate the "routing tokens," as this term must properly be 
construed for the claims of the present application. 

Another notable distinction between the invention of claim 1 and Nakai is observed in 
connection with the rejection in which the Office Action has applied the proxy server of 
Nakai as allegedly anticipating the claimed "transport gateway." This reflects a fundamental 
misunderstanding of claim 1, and a misapplication of Nakai. Among other features, claim 1 
recites: "a transport gateway computer connected to the global-area computer network;" and 
"a plurality of server computers connected to the transport gateway." In contrast, Nakai 
teaches that a "proxy server is present between the client and server, and intervenes in 
communication therebetween" (see Abstract). There is no teaching of the proxy server 
having a plurality of server computers connected to us (as the claimed transport gateway 
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requires)." This and other fundamental distinctions are apparent when considering the 
purpose and environment of the present invention, as contrasted between the purpose and 
environment of Nakai. In Nakai, the purpose is essentially protocol conversion (as opposed 
to a purpose of embodiments of the present invention, which is for relaying content upstream 
or downstream through a gateway, in such a manner that the client does not have to know the 
identity of the server at the far end). 

In short, and as noted above, the present (FINAL) Office Action ultimately repeated 
its previous rejections word-for-word. In responding to Applicant's previous remarks, the 
Office Action maintained its position by: 

1) equating the claimed repositories with Nakai' s use of directories or file names; 

2) equating the claimed "routing tokens" with Nakai' s use of a resource name; and 

3) equating the claimed "transport gateway" with Nakai' s use of a proxy server. 
These equated concepts are simply not similar and cannot be properly equated. For example, 
the claimed routing tokens describe the client so that the end-server can be inferred by the 
transport gateway. However, in Nakai, the resource name must exactly match the name at the 
end server. 

Again, functional differences such as this underscore the significance of the claimed 
subject matter, such that the applications made by the Office Action cannot properly be 
sustained. 

For purposes of defining claim 1 over the cited Nakai reference, suffice it to say that 
Nakai fails to disclose the "selecting a repository . . . based on one or more routing tokens. . ." 
element of this claim, and for at least this reason the rejection should be withdrawn. For at 
least this reason, the rejection of claim 1 should be withdrawn. 
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Dependent Claims 2-11 

Claims 2-11 each depend from claim 1, and therefore patently define over the 
applied art for at least the same reasons described above. 

Independent Claim 12 

The Office Action rejected independent claim 12 under 35 U.S.C. § 102(b) as 
allegedly anticipated by Nakai. For at least the reasons set forth below, Applicant 
respectfully traverses these rejections. 

Claim 12 recites: 

12. A method of transferring file information between one or more 
client computers and one or more server computers over a global-area 
computer network, the method comprising: 

receiving a file transfer request from a client computer; 

selecting a repository on one of the server computers based on one 
or more routing tokens in the file transfer request, wherein the routing 
tokens include one or more attributes describing the file, the client 
computer or an originator of the file transfer request; and 

performing the requested file transfer. 

{Emphasis added.) Applicant respectfully submits that the rejection is misplaced for at least 
the reason that the cited art does not disclose the features emphasized above. 

The features emphasized above closely parallel the distinguishing features of claim 1 , 
which have been fully described above. Applicant, accordingly, submits that claim 12 
patently defines over the cited art for at least the same reasons described above in connection 
with claim 1. Therefore, Applicant submits that the rejection of claim 12 be withdrawn. 

Dependent Claims 13-18 

Claims 13-18 each depend from claim 12, and therefore patently define over the 
applied art for at least the same reasons described above. 
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Independent Claim 19 

The Office Action rejected independent claim 19 under 35 U.S.C. § 102(b) as 
allegedly anticipated by Nakai. For at least the reasons set forth below, Applicant 
respectfully traverses these rejections. 

Claim 19 recites: 

19. A computer-readable storage medium comprising a routing 
computer program executable by a transport gateway connected to one or 
more client computers and one or more server computers, the transport 
gateway computer program comprising computer instructions for: 

receiving a file transfer request from a client computer; 

selecting a repository on one of the server computers based on one 
or more routing tokens in the file transfer request, wherein the routing 
tokens include one or more attributes describing the file, the client 
computer or an originator of the file transfer request; and 

performing the requested file transfer. 

(Emphasis added.) Applicant respectfully submits that the rejection is misplaced for at 
least the reason that the cited art does not disclose the features emphasized above. 

The features emphasized are identical to the features emphasized in independent claim 
12, above closely parallel the distinguishing features of claim 1, which have been fully 
described above. Applicant, accordingly, submits that claim 12 patently defines over the 
cited art for at least the same reasons as claim 12. Therefore, Applicant submits that the 
rejection of claim 19 be withdrawn. 



Dependent Claims 20-29 

Claims 20-29 each depend from claim 19, and therefore patently define over the 
applied art for at least the same reasons described above. 
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Independent Bases of Patentability of Claims 9-11 and 27-29 

In addition to the fact that claims 9-11 and 27-29 depend from claims 1 and 19 

(respectively), and therefore patently define over the cited art for at least the same reasons 

set forth in connection with claims 1 and 19 above, Applicant further continues to traverse 

the combination of Nakai and Schloss as improper. The Office Action (first paragraph of 

page 3) responds to Applicant's previous argument by citing col. 4, lines 1-12 of Schloss as 

allegedly providing the required motivation to combine this reference with Nakai. This 

portion of Schloss states: 

As shown in FIG. 1, the Web 2 includes a plurality of clients 4 (three 
shown) that interface to a plurality of content servers 6 (three shown) 
over the Internet 8. The content servers retrieve and/or generate content 
data from information stored in a data base 7 associated with the content 
server 6. Typically, the data base resides on a hard disk associated with 
the content server. A gateway 10 may be utilized to interface more than 
one client 4 to the Internet 8 as shown. Typically, the gateway 10 
functions as a proxy server to cache the most recently requested content 
data, to control access to the Interact 8 to only specified clients 4, and 
for billing the clients 4 for access to the Internet 8. 

Simply stated, this above-quoted portion does not supply ANY proper motivation for 
combining the other cited teachings of Schloss with Nakai. In this regard, it is well-settled 
law that in order to properly support an obviousness rejection under 35 U.S.C. § 103, there 
must have been some teaching in the prior art to suggest to one skilled in the art that the 

4 

claimed invention would have been obvious. W. L. Gore & Associates, Inc. v. Garlock 

Thomas, Inc. , 721 F.2d 1540, 1551 (Fed. Cir. 1983). More significantly, 

"The consistent criteria for determination of obviousness is whether the prior 
art would have suggested to one of ordinary skill in the art that this [invention] 
should be carried out and would have a reasonable likelihood of success, 
viewed in light of the prior art. ..." Both the suggestion and the expectation of 
success must be founded in the prior art, not in the applicant's disclosure... In 
detennining whether such a suggestion can fairly be gleaned from the prior 
art, the full field of the invention must be considered; for the person of 
ordinary skill in the art is charged with knowledge of the entire body of 
technological literature, including that which might lead away from the 
claimed invention. " 
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(Emphasis added) In re Dow Chemical Company , 837 F.2d 469, 473 (Fed. Cir. 1988). 

In this regard, Applicant notes that there must not only be a suggestion to combine the 
functional or operational aspects of the combined references, but that the Federal Circuit also 
requires the prior art to suggest both the combination of elements and the structure resulting 
from the combination. Stiftung v. Renishaw PLC , 945 Fed.2d 1173 (Fed. Cir. 1991). 
Therefore, in order to sustain an obviousness rejection based upon a combination of any two 
or more prior art references, the prior art must properly suggest the desirability of combining 
the particular elements to create a system and method for transferring file information 
between one or more client computers and one or more server computers over a global-area 
computer network, as claimed by the Applicant. 

Significantly, where there is not apparent disadvantage present in a particular prior 
art reference, then generally there can be no motivation to combine the teaching of another 
reference with the particular prior art reference. Winner Int'l Royalty Corp. v. Wang , No 
98-1553 (Fed. Cir. January 27, 2000). 

For at least these additional reasons, the rejections of claims 9-11 and 27-29 should 
be withdrawn. 

CONCLUSION 

Applicants respectfully submit that all claims are in proper condition for allowance, and 
respectfully request that the Examiner pass this case to issuance. If, in the opinion of the 
Examiner, a telephonic conference would expedite the examination of this matter, the Examiner 
is invited to call the undersigned attorney at (770) 933-9500. 
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No fee is believed to be due in connection with this Response to FINAL Office 
Action. If, however, any fee is deemed to be payable, you are hereby authorized to charge 
any such fee to Hewlett-Packard Company's Deposit Account No. 08-2025. 



Please continue to send all future correspondence to: 

Hewlett-Packard Development Company, L.P. 
Intellectual Property Administration 
P.O. Box 272400 

Fort Collins, Colorado 80527-2400 



Respectfully submitted, 




Daniel R. McClure 
Registration No. 38,962 
(770) 933-9500 
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